ChainForge 論文
https://scrapbox.io/files/65bc5e27d6cb080024d4e9ab.png
論文情報
タイトル：ChainForge: A Visual Toolkit for Prompt Engineering and LLM Hypothesis Testing
発行日：2023年9月
著者：Ian Arawjo, Chelse Swoopes, Priyan Vaithilingam, Martin Wattenberg, Elena Glassman
所属：Harvard University
論文を読んで感じたこと
プロンプトとモデルの決定が、とても主観的なことに問題を呈している
LLMOpsで、この図は的を得ている
https://scrapbox.io/files/65bc6385521c6000262e3084.png
この探索と評価を橋渡しするツールを作りたかったとのこと
納得...!!
作者への圧倒的感謝😭
一部の潜在的なユーザーは、自分のマシンにインストールする必要があることに懸念を抱いていました。したがって、バックエンドをPythonからTypeScriptに書き換え（2000行以上のコード）、ChainForgeをウェブ上でホストするようにしました。これにより、誰でもサイトを訪れるだけでインターフェースを試すことができます。さらに、「共有」ボタンを追加し、ユーザーが実験をリンクとして他の人と共有できるようにしました。
ChainForgeを使う時、プログラミングをしたことのないユーザーは、変数のところで躓いた。しかしテンプレートの作成法を学んだ後、この問題は解決した。
PromptFoo知らなかった
概要
大規模言語モデル（LLM）の出力を評価することは、多くの応答を生成し、それらを理解することを要求するため、難しい課題です。しかし、基本的なプロンプト指示を超えるツールは、プログラミングAPIの知識を必要としたり、狭い領域に焦点を当てたり、オープンソースでない場合があります。我々は、プロンプトエンジニアリングとテキスト生成LLMのオンデマンド仮説検証を支援する、オープンソースの視覚的ツールキットであるChainForgeを紹介します。ChainForgeは、モデルとプロンプトのバリエーションを横断してレスポンスを比較するためのグラフィカルインターフェースを提供します。私たちのシステムは、モデル選択、プロンプトテンプレートの設計、および仮説検証（例えば、監査）といった3つのタスクをサポートするように設計されました。我々はChainForgeをその開発の初期段階でリリースし、学術界およびオンラインユーザーとのデザインに関する反復作業を行いました。ラボ内およびインタビュー調査を通じて、我々は、さまざまな人々が彼らにとって重要な仮説を調査するためにChainForgeを使用できることを発見しました。これには実世界の環境も含まれます。我々は、プロンプトエンジニアリングとLLM仮説検証の3つのモードを特定しました：機会的探索、限定的評価、反復的改良。 1 導入
大規模言語モデル（LLM）は、世界中で想像力と懸念を捉えています。想像力と懸念の両方が、部分的にはモデルの能力に関するあいまいさから生じています—LLMの振る舞いを特徴づける難しさです。開発者からモデル監査人まで、誰もがこの同じ挑戦に直面しています。開発者は「プロンプトエンジニアリング」、つまり一貫した品質の出力につながるプロンプトを見つけることに苦労しています。モデルのバイアスをチェックするための監査人は、仮説を系統的にテストするためにプログラミングAPIを学ぶ必要があります。LLMを解明するためには、人々が単一のプロンプトやチャットを超えてLLMの振る舞いをより包括的に理解するのを助ける強力でアクセスしやすいツールが必要です。
この論文では、オープンドメインのタスクでテキスト生成LLMの振る舞いのオンデマンド仮説検証をサポートする視覚ツールキット、ChainForgeを紹介します。これは、ほとんどまたは全くコーディングが必要ない状況で使用できます。我々は、大学での実際の使用例から動機付けられたChainForgeの設計について説明し、同僚の学者およびオンラインユーザーからのフィードバックによって私たちの設計がどのように進化したかを説明します。2023年初夏以来、ChainForgeはchainforge.aiでウェブおよびローカルソフトウェアとして一般に公開されており、無料かつオープンソースであり、ユーザーが実験をファイルやリンクとして他者と共有できるようにしています。HCIの他のシステム作業とは異なり、我々はChainForgeをオープンに開発し、閉ざされた作業や「プロトタイプを作成して先に進む」パターンの代替案を求めました。その発売以来、我々のツールは多くの人々によって使用されており、この会議に提出された他のHCI研究プロジェクトを含む他のプロジェクトでも使用されています。我々は、コンピューティングの背景を持たない人々を含む一連の参加者を巻き込んだ定性的なユーザースタディを報告します。我々の目標は、ユーザーが彼らにとって重要なタスクにChainForgeをどのように適用したか、ツールの強みと限界を位置づけ、将来のインターフェースに対する含意を提示することでした。我々は、ユーザーが物質特性の理解から、言語間のモデル出力における微妙なバイアスを発見するまで、さまざまな調査にChainForgeを適用できたことを示します。小規模なインタビュースタディを通じて、実際のユーザーが実世界のタスクにChainForgeを有用であると感じ、そのソースコードを拡張し、ラボ内のユーザーとの使用方法の違いについて述べていることがわかりました。HCIの「ツールキット」または建設的研究と一致して、我々の貢献は以下の通りです：
ユーザーと反復的に開発された公開されているオープンソースのアーティファクトであるChainForge
LLMの振る舞いのオープンエンドでオンデマンドの仮説検証のためのシステムに関するラボ内のユーザビリティとインタビュー研究
LLM出力のプロンプトエンジニアリングと仮説検証をターゲットとする将来のツールに対する含意
研究を横断して、我々はプロンプトエンジニアリングとLLM仮説検証の3つのモードをさらに特定しました：機会的探索、限定的評価、反復的改良。これらのモードは、プロンプトエンジニアリングと仮説検証を行う際の異なる段階とユーザーのマインドセットを強調しています。設計の貢献として、我々はHCI文献においてクロスLLM比較をサポートする最初のプロンプトエンジニアリングツールの一つを提示し、プロンプトテンプレートの連鎖という概念を紹介します。これはAIチェーンの拡張であり、プロンプトテンプレートが再帰的にネストされることがあります。
我々の調査では、多くのユーザーがChainForgeが我々の設計目標であるタスクや行動（モデル選択、迅速な反復、仮説検証）に有効であることを認めており、中にはJupyter notebookのようなツールよりも効率的であると認識しているユーザーもいました。構造化されたタスクに関する我々の発見は、プロンプトとモデルの周りの決定が非常に主観的であることを示唆しています：同じ基準とシナリオが与えられても、ユーザーの解釈と基準のランキングは大きく異なることがあります。最後に、多くの実世界のユーザーが我々が予想していなかったニーズのためにChainForgeを使用していることがわかりました：データ処理パイプラインのプロトタイピング。以前の研究はAIチェーンまたはプロンプトエンジニアリングに焦点を当てていますが、実際の人々がなぜプロンプトエンジニアリングを行ったり、AIチェーンをプログラムしたりするのかについてほとんどまたは全くコンテキストを提供していません。我々は、ユーザーのサブタスクが我々の設計目標（例えば、プロンプトテンプレートの反復、モデルの選択）に一致していることを発見しましたが、これらのサブタスクは通常、2つの包括的な目標のいずれかに奉仕していました—データ処理パイプラインのプロトタイピング、またはモデルの振る舞いのテスト（例えば、監査）。プロンプトエンジニアリングをデータ処理のより大きな文脈に置いたとき、我々の実世界のユーザーの独特のニーズと痛点—データの取り出し、他者との共有—は、後知恵で明らかに見えます。我々は、将来のプロンプトエンジニアリングやAIチェーンのシステムがプロンプト/チェーンの反復自体を超えてユーザーのより広いコンテキストと目標を考慮し、特に、過去のデータ処理フレームワークからのインスピレーションを得ることを推奨します。
2. 関連研究
過去10年間で、機械学習（ML）への関心の高まりが、MLオペレーション（「MLOps」）用のソフトウェア業界を生み出しました。ツールは一般的にMLの専門家を対象としており、データセットのキュレーションからトレーニング、パフォーマンスの評価（例：Google Vertex AI）まで、MLパイプライン全体のタスクをカバーしています。LLMは独自のユニークな課題とユーザーを持ち込みました。LLMは、すべての可能な使用例を通じて完全に評価するには大きすぎます。しばしばブラックボックス化されているか、または「説明」することが事実上不可能です。そして、適切なプロンプトやモデルを見つけることは、それ自体が産業となっています。これらの問題を複雑にすることに、LLMのユーザーはしばしばMLの専門家では全くありません。例えば、バイアスをチェックする監査人や非MLのソフトウェア開発者などです。したがって、LLMは独自のインフラストラクチャとツールエコシステム（「LLMOps」）を活発にしています。
LLMOpsの領域は急速に進化しています。私たちは、この新興のエコシステムをグラフとして表現しています（Figure 2）
https://scrapbox.io/files/65bc6385521c6000262e3084.png
探索と発見が一方の端にあり（例：プレイグラウンド、ChatGPT）、もう一方の端にLLMの出力の体系的な評価とテストがあります。この水平軸は、プロンプトエンジニアリングの2つの関連する異なる部分を表しています：ユーザーの基準に従って堅牢に機能するプロンプトを発見すること、プロンプトと基準の両方で即興と実験を伴うプロセス；そして一度選ばれたプロンプトを評価すること、通常はプロンプトの変更がユーザーエクスペリエンスを変えないようにするために、製造コンテキストで行われます。（これらの段階は、「チェーン」やAIエージェントにも一般化されます。）これら2つの側面は、Jupyter Notebooksのような環境が乱雑な探索と迅速なプロトタイピングをサポートする一方で、自動化されたパイプラインが品質管理を保証するソフトウェアエンジニアリングに類似しています。垂直軸は、テキストAPIからグラフィカルユーザーインターフェース（GUI）を持つツールまで、相互作用のスタイルを特徴付けます。以下では、この風景の特定の部分にズームインします。 プロンプトエンジニアリングのためのLLMOps
LLMを促進するために設計された学術プロジェクトの数が増えていますが、テキスト応答の体系的な評価をサポートするものはほとんどありません。例えば、PromptMakerはユーザーが数発の例を用いてプロンプトを作成するのを助けますが、著者はユーザーがプロンプトを「体系的に評価することが難しい」と結論付け、レスポンスをスコアリングできればよいと願い、そのようなスコアリングは「ユーザーの使用例に非常に特化している…むしろ一般的に適用可能なメトリックではない」と述べています。テキスト生成のためのプロンプト評価を扱う珍しいシステムの一つにPromptAidがあり、これはNLPの言い換えモデルを使用して意味的に類似した言い換えで入力プロンプトを摂動させ、単一のLLMにクエリを再送し、評価スコアをプロットします。概念的には強力ですが、テストは感情分析タスクにのみ適用され、テストプロンプト、モデル、評価メトリックがユーザーに事前定義されていました。BotDesignerは、チャットモデルのプロンプトベースの設計をサポートしていますが、その評価も特定のタスク（AIプロのシェフの作成）を中心に非常に構造化されていました。ユーザーが自分たちにとって重要なオープンエンドのタスクをサポートし、特に複数のLLMを横断して比較し、自分たちのメトリックを設定する方法は依然として不明です。これにより、即興的かつ体系的な方法でLLMの振る舞いについての仮説をテストできるようになります。 ChainForgeを発表して以来、商業的なプロンプトエンジニアリングおよびLLMOpsツールが登場し、毎日のように新しいものが出現しています。例えば、Weights and Biases Prompts、nat.dev、Vellum.ai、Vercel、Zeno Build、およびpromptfooがあります。これらのシステムは、プロンプトのサンドボックスから製品アプリケーション内のプロンプト検証およびバージョニングに至るまでさまざまです。通常、コード、コマンドラインスクリプト、または設定ファイルとの統合に依存しています。例えば、promptfooはjestのようなテストフレームワークに似た評価ハーネスで、ユーザーがプロンプトと期待される出力を指定する設定ファイルを書きます。テストはコマンドラインから実行されます。ほとんどのシステムがプロンプトテンプレートをサポートしていますが、複数のモデルに一度に各プロンプトを送信するものは少なく、Vellum.aiのようにクロスモデル比較をサポートするものは、単一のプロンプトをテストするプレイグラウンドであり、体系的に比較するのが面倒です。
LLMOpsのための視覚的データフロー環境
評価の設計上の懸念とは視覚的に関連しているが異なるのは、LLMの応答を中心に構築された視覚的データフロー環境です。これには2つのフレーバーがあります：情報の探索のための意味作りインターフェイスと、LLMアプリケーションの設計ツールです。前者のインスタンスであるGraphologueとSensecapeは、ユーザーがチャットLLMと非線形に対話し、たとえばその回答を詳しく説明する機能を提供することに焦点を当てています。2つ目は、LangChain Pythonパッケージと通常統合されるLLMベースのアプリケーションの設計システムです：Langflow、Flowise、およびMicrosoft PromptFlow on Azure services。これら3つのツールは、WuらによるLLMアプリ開発のためのクローズドソースの視覚的プログラミング環境であるPromptChainerに先行していました。これらの環境は、「AIチェーン」、つまりLLMと他のツールやスクリプト間のデータフローの構築に焦点を当てています。ここでは、視覚的フローベースのツールからの設計コンセプトを活用しつつ、LLM応答品質の探索と評価をサポートする設計に焦点を当てています。一つの重要な違いは、仮説検証ツールが組み合わせの力をサポートする必要があることです。つまり、複数のモデルに一度に複数のプロンプトを問い合わせることですが、LLMアプリの構築および意味作りツールは単一の応答とモデルに焦点を当てています。 全体として、進化するLLMOpsの風景は次のようにまとめることができます。プロンプト発見のためのツールは、ユーザーが試行錯誤を通じて一度に単一のプロンプトを送信する単純なプレイグラウンドやチャットに大きく限定されているようです。一方、体系的なテストのためのツールは、特有の設定ファイル、コマンドラインの呼び出し、MLエンジニアリングの知識、またはプログラミングAPIとの統合を要求する傾向があります。これにより、発見と即興（プログラマー以外の人にとっては言うまでもなく）に使用するのが難しくなっています。私たちは、探索と評価の側面を橋渡しするシステムを設計したいと考えていました：迅速な発見と反復を容易にするグラフィカルインターフェイス、しかし多くの応答の検査と体系的な評価も、プログラミングAPIの広範な知識を必要とせずに行えるようにします。視覚プログラミングツールの使いやすさと、複数のLLMに同時に同じプロンプトを送信するようなパワー機能を組み合わせることで、人々がLLMの振る舞いを実験し、特徴付けることを容易にすることを目指しました。
3 設計目標と動機
ChainForgeの原動力は、他の研究プロジェクトのためにLLMを搭載したソフトウェアを開発しながらプロンプトをテストする私たち自身の経験から来ています。私たちの研究室全体で、特定の基準を満たすプロンプトに到達するために、プロンプトを体系的にテストする方法が必要でした。この基準はプロジェクト固有のものであり、開発が進むにつれて即興的に進化しました。また、LLMの振る舞いを評価しようとする際に、他の研究者や業界の開発者が似たような問題に直面していることにも気づきました。私たちは、LLMの振る舞いに関する仮説検証のカテゴリに入る幅広いタスクのためにChainForgeを設計しました。仮説検証にはプロンプトエンジニアリング（プロンプトを見つけることは、プロンプトに関する仮説を思いつき、それらをテストすることを含みます）が含まれますが、セキュリティ、バイアス、公平性などのモデルの監査も包括します。具体的には、私たちのインターフェースは以下の4つの具体的なユーザーゴールと行動をサポートすることを意図していました：
D1. モデル選択。モデルを横断してLLMの振る舞いを簡単に比較します。私たちはLLMのファインチューニングに動機付けられ、ファインチューニングされたモデルとベースモデルで何が変わったかを「評価」する方法について考えました。ユーザーは、どのモデルを使用するか、または自分のユースケースに対して「最良」のパフォーマンスを発揮するかについて、迅速に洞察を得ることができるべきです。
D2. プロンプトテンプレート設計。プロンプトエンジニアは通常、良いプロンプトではなく、多くの可能な入力に対して一貫してパフォーマンスを発揮する良いプロンプトテンプレート（{braces}の中に変数を持つプロンプト）を見つける必要があります。既存のツールでは、テンプレート間の違いを並べて比較することが難しく、したがって迅速なイテレーションを妨げています。
D3. 体系的評価。逸話的な証拠を超えてLLMの振る舞いに関する仮説を検証するためには、多くのレスポンス（理想的にはプロンプトごとに複数のレスポンス）が必要です。しかし、レスポンスの手動検査（スコアリング）はすぐに時間がかかり、扱いにくくなります。これを是正するために、システムは大量のパラメータ化されたクエリを送信し、ユーザーがそれらを自分自身の特異な基準に従ってナビゲートしてスコアリングするのを支援し、結果を迅速にスキミングする（例えば、プロットを介して）必要があります。
D4. 即興。私たちは、迅速かつ雑な反復をサポートし、その役割をソフトウェアエンジニアリングのJupyter Notebooksになぞらえたシステムを想像しました。探索の過程でユーザーが別の仮説を思いつき、それをテストしたい場合、システムはその仮説のオンデマンドテストをサポートするべきです。プロンプトの修正、モデルの入れ替え、評価の変更などです。この設計目標はD3と緊張関係にあり、時にはレスポンス品質の測定において不正確さを受け入れることさえあります。私たちはシステムが詳細な評価を行うことができると想像しましたが、私たちの主な目標はオンデマンド（論文品質とは対照的に）の評価をサポートすることでした。
また、2つの高レベルの目標がありました。システムが「基本的なこと」—例えば、複数のモデルに一度にプロンプトを送信し、グラフをプロットし、レスポンスを検査すること—を処理するようにし、研究者がより微妙な研究質問を可能にするために私たちのプロジェクトを拡張または活用できるようにしたいと考えました（例えば、独自の視覚化ウィジェットを設計する）。次に、典型的なHCIシステム研究とは異なり、オンラインユーザー自身がGitHub経由でプロジェクトにフィードバックを提供できるように、オープンソースの反復を探求したいと考えました。部分的には、HCIでのクローズソースまたは「プロトタイプを作成して先に進む」作業パターンに対する幻滅に動機付けられました。これは生態学的妥当性をリスクにさらし、公益よりも学術的な名声を優遇する傾向があります。最後に、人間の学習の差別化と豊かさの理論、変化理論と類推学習理論に導かれました。これらは、（構造的に）整列した、多様なデータ内の変化の価値に関する補完的な視点です。両理論は、学習の対象物（この場合、モデル、プロンプトおよび/またはプロンプト変数）内外での変化を経験することが、人間が新しいシナリオにより堅牢に一般化するより正確なメンタルモデルを開発するのに役立つと主張します。ChainForgeは、ユーザーが複数のモデル、プロンプト、および/またはプロンプト変数の値を選択することによって、ユーザーが学びたいことに応じて構築する、類似の違いを横断するこれらの並置を設定するのに役立つインフラを提供します。
ChainForgeは、プロンプトインジェクション攻撃に対してLLMを堅牢にするという現実世界のニーズに関連する使用例を通じて、詳細に説明する前に、まず読者を1つの使用シナリオを紹介します。このシナリオは、Google DocのAIライティングアシスタントとのやり取りから派生しており、ツールが強調表示されたテキストの書き換えを提案するはずが、代わりにテキストをコマンドとして受け取った例です。使用例の詳細なケーススタディは、私たちの調査結果で提示されます。
Farahは、ユーザーがドキュメント内のテキストをハイライトし、ボタンをクリックしてテキストを拡張、短縮、または書き換えることができるAIライティングアシスタントを開発しています。コード内では、プロンプトテンプレートを使用し、ユーザーの入力をコマンドの下の変数としてフィードします。しかし、モデルがプロンプトインジェクション攻撃に対して堅牢か、またはユーザーが意図的にモデルを誤動作させようとするかどうかについて心配しています。彼女はいくつかのモデルを比較し、最も堅牢なものを選択することに決めました。重要なことは、迅速に結論に達し、カスタムプログラムの作成を避けたいと考えています。
ChainForgeをロードした後、FarahはPrompt Nodeを追加し、プロンプトテンプレートを貼り付けます。彼女は3つのコマンドプロンプトをTextFields Nodeに入れ、テキストを拡張、短縮、書き換える3つのボタンを表し、モデルが指示を無視して単に「LOL」と出力するようにするいくつかのインジェクション攻撃を2番目のTextFieldsに入力します。彼女はTextFieldsをそれぞれテンプレート変数{command}と{input}に接続します。Promptノードに4つのモデルを追加し、「Num responses」を変化に富んだ3に設定して実行し、入力のすべての順列に対してすべてのモデルからのレスポンスを収集します。JavaScript Evaluatorを追加すると、レスポンスがLOLで始まるかどうかをチェックし、攻撃が成功したことを示し、成功率をプロットするためにVis Nodeに接続します。
15分後、FarahはすでにGPT-4が最も堅牢であるように見えることを確認できますが、GPT-3.5もそれほど遅れていません。彼女はフローを同僚に送り、GPT-4がより高価であることを考慮してどのモデルを選択するかについて話し合います。チームはGPT-3.5を選択することに同意しますが、同僚はGPTモデル以外をすべて削除し、インジェクションスタイルの攻撃を聞かないようにする声明を含む、コマンドプロンプトの異なるバリエーションを試すことを提案します...
Farahと彼女の同僚は、プロンプト、テスト基準などについて繰り返しChainForgeを使用するか、またはモデルを決定して先に進むかもしれません。期待される使用法は、チームが迅速に結論に達するためにChainForgeを使用し、その後、実装のために他の場所に進むことです。Farahのタスクは「プロンプトエンジニアリング」の範疇に入るかもしれませんが、監査コンポーネントもあり、私たちはこの例を超えたさまざまなシナリオをサポートするようにシステムを設計しました。
4.1 設計概要
ChainForgeのメインインターフェースはFigure 1に示されています。
https://scrapbox.io/files/65bc67ead39fbc002432812c.png
データフロープログラミング環境に共通して、ユーザーはノードを追加し、エッジでそれらを接続できます。ChainForgeには、入力、ジェネレーター、評価器、ビジュアライザーの4種類のノードがあります。また、コメントノードのような雑多なものもあります（利用可能なノードは付録A、表3にリストされています）。この類型はKim et al.の「セル、ジェネレーター、レンズ」のLLMフレームワークと大まかに一致していますが、問題のクラスとノードのタイプがより広範です。PromptChainerのように、ノード間を流れるデータは通常、メタデータが添付されたLLMのレスポンスです（入力ノードはテキストをエクスポートします）。表1は、セクション3の設計目標とどのように実装の側面が関連しているかを説明しています。
https://scrapbox.io/files/65bc69d2521c6000262eb7cd.png
ノードと機能に関する包括的な情報については、補足資料およびchainforge.ai/docsで提供されているドキュメントを参照してください。これ以降、私たちは仮説検証に関連するユニークな高レベルの設計課題に焦点を当てて説明します。ChainForgeと他のフローベースのLLMOpsツールとの主な設計の違いは、組み合わせの力です—ユーザーは複数のプロンプトだけでなく、複数のモデルにクエリを送信でき、階層的に整理されたプロンプト変数（チェーンされたテンプレートを通じて）や追加のメタデータを持つことができます。これにより、「マルチバース問題」と呼ばれるユニークな設計が生まれます。この設計のユニークな点は、ユーザーが一度に複数のモデルにクエリを送信できるPrompt Nodeです。多くの機能は、ユーザーが出力のマルチバースをナビゲートし、それらの間で結論に達するための複雑さを減らすことを目指しています。ChainForgeは、ユーザーが出力の多様性をナビゲートし、複雑さを軽減して結論に至るための多くの機能を提供します。これには、レスポンスインスペクタ、評価者、および視覚的なプロットなどが含まれます。ChainForgeでLLMクエリを生成する際の組み合わせの複雑さは、大まかに以下の式でまとめられます：
https://scrapbox.io/files/65bc6adc358cc100247825b1.png
ここで、\(P\)はプロンプト変数の組み合わせを通じて生成され、\(M\)は応答提供者（モデルのバリエーション、AIエージェントなど）に一般化され、\(C\)はプロンプトノードに対しては0、チャットターンノードに対しては0以上です。\(P\)プロンプトは、テンプレートに複数の入力変数を使用することでセットのクロスプロダクトを生成するシンプルなルールを通じて生成されますが、タブラーデータノードの出力は、テンプレート変数を埋めるときに「一緒に運ばれます」。
レスポンスを検査するために、ユーザーはポップアップのレスポンスインスペクタを開きます。インスペクタには2つのレイアウトがあります：グループ化リストでは、ユーザーは同じプロンプトに対するLLMのレスポンスを横に並べて見ることができ、入力変数に基づいて階層的にレスポンスをグループ化して整理することができます。テーブルでは、ユーザーの選択によって入力変数および/またはLLMをプロットする列があります。両方のレイアウトは、単一のプロンプトに対するLLMのレスポンスを色付きのボックスで表示し、各色は特定のLLMにマッピングされ、アプリケーション全体で一貫しています。グループ化リストには、デフォルトで1つが開かれている折りたたみ可能なレスポンスグループがあり、ユーザーはヘッダーをクリックしてグループを展開/折りたたむことができます。テーブルレイアウトでは、すべての行が一度に表示されます。パイロットテストで、ユーザーとタスクによって、どちらかのビューを好むことが観察されました。
限られたスペースでカバーできる以上の機能がありますが、ChainForgeのさらなる認識を提供するために、タブラーデータとシンプルな評価ノードを使用してOpenAIの評価ベンチマークに対するグラウンドトゥルース評価を行う、より複雑な例を紹介します。各ステップで、メタデータ（プロンプトテンプレートの「記入履歴」）が出力に注釈を付け、チェーン内の下流で参照されることがあります。ここでは、「理想的」列がシンプルな評価器でメタ変数として使用され、LLMの応答が期待される値を含んでいるかどうかをチェックします。「理想的」はテンプレートへの入力ではなく、テーブルのおかげでプロンプトへの出力と関連付けられています。ユーザーはコマンドごとにプロットして、2つのプロンプト変数間のパフォーマンスの違いを比較します。積み上げ棒グラフをスポットチェックすると、ClaudeとFalcon.7Bが一方のコマンドよりも他方のコマンドでわずかに優れていることがわかります。
4.2 オンラインおよびパイロットユーザーとの反復開発
パイロットユーザー（コンピューティング分野の学者）およびオンラインユーザー（公開GitHubのIssuesやコメントを通じて）と共に、ChainForgeを反復しました。その結果生じた重要な変更と追加を要約します。
ChainForgeの開発初期に、私たちは研究室で進行中の研究プロジェクトでそれをテストしました。最も重要な成果は、テンプレートが再帰的にネストされるプロンプトテンプレートのチェーン化の開発であり、プロンプトテンプレート自体を横断して比較することを可能にしました。ChainForgeの初期の使用例には、最小限の言い換えでテキストを短縮すること、どのプログラミングAPIがどのプロンプトにインポートされたかをチェックすること、およびレスポンスがドメイン固有言語にどれだけ適合しているかを評価することが含まれます。例えば、「単語のみを削除」タスクに対して、私たちが使用していたChatGPTプロンプトが最も悪いパフォーマンスを示し、他のプロンプトと比較して最も言い換えを行う傾向があることがわかりました。
また、5つのパイロット研究を実施しました。パイロットユーザーは、コードなしでレスポンスをスコアリングする簡単な方法と、チャットコンテキストを維持する方法を要求しました。これらの機能はLLMスコアラーとチャットターンノードとして実現されました。最後に、一部の潜在的なユーザーは、自分のマシンにインストールする必要があることに懸念を抱いていました。したがって、バックエンドをPythonからTypeScriptに書き換え（2000行以上のコード）、ChainForgeをウェブ上でホストするようにしました。これにより、誰でもサイトを訪れるだけでインターフェースを試すことができます。さらに、「共有」ボタンを追加し、ユーザーが実験をリンクとして他の人と共有できるようにしました。
2023年5月下旬の発売以来、オンラインユーザーもGitHubのIssuesを通じて私たちのシステムにフィードバックを提供しました。PyPI統計によると、ChainForgeのローカルバージョンは約5000回インストールされ、公開GitHubは1300以上のスターを獲得しました。2023年8月、世界中の国々から3000人以上のユニークユーザーがウェブアプリにアクセスし、日平均で約100人（トップ国：アメリカ、韓国、ドイツ、インド）でした。オンラインコメントには、以下のようなものが含まれます：
ビッグ5テック企業のソフトウェア開発者、GitHub Issue経由：「同僚にこれを見せたところ、皆、このツールの力と柔軟性に驚嘆しました。素晴らしい仕事です！」
スタートアップの開発者、著名なプログラマーニュースサイト上で：「プロジェクトでこれを使ったところ、非常に役立ちました！ここで見るのはクールです」
トップML企業のプロダクトデザイン責任者、ソーシャルメディアサイト上で：「ちょっとChainForgeで遊んでみてLLMを比較しましたが、UXは満足できるものでした」 バグの特定だけでなく、オンラインフィードバックにより、MicrosoftのAzure OpenAIサービスへのサポート追加、プロンプトを送信する前にプレビューする方法、TextFieldsノードのフィールドを「オン」または「オフ」に切り替える機能、異なるホストとポートでの実行、暗黙のテンプレート変数の追加が行われました。発売以来、ChainForgeのコードは他の2つの研究チームによっても採用されています。一つは最終著者に関連するチームで、もう一つはHCI研究におけるLLMイメージモデルとのプロトタイピングに私たちのコードを適応させているアメリカの研究大学の関連のないチームです（私たちは評価で彼らにインタビューしました）。
4.3 実装
ChainForgeは第一著者によってReact、TypeScript、Pythonでプログラミングされました。フロントエンドのUIにはReactFlowを、UI要素にはMantineを使用しています。ローカルバージョンでは、アプリを提供し環境変数からAPIキーを読み込むためにFlaskを使用しています。プロンプトの置換とAPIリクエストの送信に関するアプリロジックはカスタムデザインされており、非同期ジェネレータ関数を使用してパフォーマンスを向上させています。これにより、複数のLLMに同時に数百のリクエストを送信し、リアルタイムで進行状況をストリームバックし、モデルプロバイダに基づいてリクエストを適切にレート制限し、他のリクエストを妨げることなくAPIリクエストエラーを収集することが可能です。ChainForgeのソースコードはMITライセンスの下で公開されています。
5 評価の理論、設計、および文脈
HCIにおいてツールキットを評価することは著しく困難です。評価の主流方法である制御されたユーザビリティスタディは、ユーザビリティスタディがツールキットの能力の狭いサブセットに焦点を当てがちであるため、ツールキットには不適合です。これは「システムが日常的にどのように採用され、使用されるか」とほとんど一致しません。ツールキット論文の評価期待を標準化するために、Ledoらは成功したツールキットの出版物が通常、四つの方法のうち二つを採用していることを発見しました。その中で最も人気のある方法は、使用例（例示シナリオ）と、ツールの幅広さを捉えようとするユーザースタディです（「ターゲットユーザーグループがどのタスクや活動を実行でき、どのタスクが依然として挑戦的なままか？」）。これらの洞察は、ChainForgeの評価方法にどうアプローチするかを形成するのに役立ちました。
私たちの研究の目標は、ChainForgeが人々が個人的に重要だと考えるLLMの振る舞いについての仮説を調査するのにどのように役立つかを調査することでした。これは、誰がそのようなツールキットを有用と考えるか、短時間で全ての能力を学ぶことの不可能性についての事前の知識の限界を認識しています。ChainForgeは広範囲のタスクに対するオープンエンドの仮説テストのために設計されているため、私たちの評価も同様にオープンエンドであり、限られた時間で可能な限りユーザーが実行したいと思っている実際のタスクのいくつかを捉えることが重要でした。そのため、我々は主に質的アプローチを取り、新しいユーザーとのラボ内ユーザビリティスタディと、実際のユーザーとの小規模なインタビュースタディ（8）を行いました。これらのユーザーは、私たちのシステムをオンラインで見つけ、実際のタスクにそれまたはそのソースコードを既に適用していた人々です。私たちは、これらの研究が私たちのツールキットの強みと弱点の丸みを帯びた感覚を提供し、ラボ内と実世界の使用法の間の潜在的な不一致を特定することを望んでいました。全体として、私たちは発見したいと思っています：
(1) 人々がChainForgeをどのように使用するかの一般的なパターンはありますか？
(2) 人々が遭遇する痛点（ユーザビリティと概念上の問題）は何ですか？
(3) 人々は既にChainForgeをどのようなタスクに役立つと感じていますか？
(4) 人々が達成したいと思っていたが、現在の機能の範囲外だと感じたり、難しいと感じたりしたタスクの種類は何ですか？
ラボ内スタディでは、研究時間の大部分を自由探索に費やしました。我々はそれをチュートリアルとモックプロンプトエンジニアリングタスクとして機能する構造化セクションと、参加者が研究者に助けと指導を求めることができる参加者のアイデアの非構造化探索に分けました。スタディ前に、我々はインフォームドコンセントを求めました。参加者は事前スタディ調査に記入し、人口統計情報、AIテキスト生成モデルの以前の経験、過去のプログラミング知識（リカートスコア1-5; 5が最高）、LLMを評価するプロジェクトに取り組んだことがあるかどうかを記入しました。その後、参加者はインターフェイスを紹介する5分間のビデオを視聴しました。
構造化タスクでは、参加者は2部構成のモックプロンプトエンジニアリングシナリオをナビゲートし、開発者が最初にモデルを選択し、次にパフォーマンスを改善するためにプロンプトを反復する場面です。私たちは参加者に「プロフェッショナルなメールに変換する」（見込みメールメッセージをよりプロフェッショナルに聞こえるように翻訳する）モデルとプロンプトを選んでもらいました。第一部では、参加者には事前にロードされたフローが与えられ、「開発者だと想像してください...」というシナリオで簡単に説明され、紙のスリップに2つの基準が提示されました：(1) 応答は翻訳されたメールだけでなければならない、そして(2) メールは非常にプロフェッショナルに聞こえるべきです。参加者は基準に基づいて「最適な」モデルを選択し、その選択を正当化するように求められました。全ての参加者は、プロンプト「次のメールをよりプロフェッショナルで丁寧なトーンに変換する」に対して、GPT-4、Claude-2、およびPaLM2からの同じキャッシュされた応答を、同じ順序で見ました。これには4つの例のメールが含まれていました（例えば、「私の最後のメールになぜ返信しなかったのですか???」）。彼らが応答を検討するのに時間を費やした後、私たちは彼らにもう1つの例を翻訳するように依頼し、プロンプトごとの応答数を増やして、同じLLMが同じプロンプトでどのように異なるかを示しました。
参加者がモデルを選択したら、私たちは彼らに選択したモデル以外のすべてを削除するように依頼しました。その後、私たちは彼らに事前に与えられた「コマンドプロンプト」をTextFieldsに抽象化し、自分の選択に基づく少なくとも2つ以上のコマンドプロンプトを追加するように導きました。スリップには3つ目の基準が与えられました：「メールは簡潔であるべきです。」参加者が応答を検査し、最適なプロンプトを決定し始めた後、私たちは彼らに1つのコードEvaluatorとVis Nodeを追加するように依頼しました。これにより、コマンド変数による応答の長さをプロットしました。プロットと少し時間を過ごした後、参加者には決定するように求められました。
残りの研究時間は、ユーザーが十分なサポートとドキュメントを提供された場合に、ChainForgeを使用して彼らにとって重要なLLMの振る舞いに関する仮説を調査する方法を模倣することを目的とした非構造化の探索セクションに費やされました。我々は参加者に研究の前日にAIテキスト生成モデルに関するアイデア、質問、または仮説を考えるように依頼しました。また、6つの可能な調査領域のリストを提供しましたが、具体的な例は提供しませんでした（例：モデルのバイアスのチェック、敵対的攻撃の実施など）。その後、研究中、参加者は研究者の助けを借りてインターフェイスを通じて自分のアイデアを探求しました。重要なことに、研究者は参加者を特定の関心領域に向けて導くのではなく、参加者の調査をサポートするように指示されました。
例外は、参加者が単一のモデルのみをクエリした場合です。
参加者は公開バージョンと全く同じインターフェースを使用し、OpenAIのgpt-3.5とgpt-4、Anthropicのclaude-2、Googleのchat-bison-001、そしてHuggingFaceのモデルへのアクセスがありました。タスクの後、我々は簡単なポストインタビュー（5-10分）を行い、参加者にインターフェースを評価するよう依頼し（1-5）、その理由を説明し、遭遇した困難、改善の提案、AIについての理解が影響を受けたかどうか、そしてなぜ再びインターフェースを使用するかどうかを尋ねました。
5.1 募集、参加者の人口統計、およびデータ分析
我々は、リストサーブ、Slackチャネル、およびフライヤーを通じて、米国に基づく大学周辺でラボ内参加者を募集しました。我々は、CSやMLに経験のある人々を超えてリーチを広げようと試み、特に人文科学と教育の参加者をターゲットにしました。参加者は一般的に20代から30代前半（9人が23-27歳、8人が28-34歳、3人が18-22歳、1人が55-64歳）で、主に男性を自己申告していました（男性14人、女性7人）、そして主にコンピューティング、エンジニアリング、または自然科学のバックグラウンドを持っていました（CS、データサイエンス、またはテクノロジーから10人、バイオエンジニアリング、物理学、材料科学、またはロボティクスから7人、教育から2人、医学から1人、デザインから1人）。彼らはAIテキスト生成モデルとの過去の経験が適度にありました（平均=3.3、標準偏差=1.0）；1人は経験がありませんでした。過去のPythonプログラミング経験は様々で（平均=3.1、標準偏差=1.3）、JavaScriptの経験は少なかった（平均=2.0、標準偏差=1.3）；2人はプログラミング経験がありませんでした。8人は「大規模言語モデルを評価する学術研究、論文、またはプロジェクトに取り組んだことがある」と報告しました。全ての参加者はラボに来て、研究は最初の3人の共著者に等しく分けられました。各研究は75分かかり、参加者には30ドルの報酬（USD）が支払われました。人間の被験者研究でのAmazonギフトカードの過剰使用に関する倫理的懸念のため、我々は全ての参加者に現金で支払いました。
私たちのインタビュー研究では、実世界のタスクにChainForgeを既に使用していた参加者を求め、ソーシャルメディア、GitHub、および学術ネットワークを通じてアプローチしました。第一著者は8人の参加者（2つのインタビューでは、2人が一緒に働いていました）と6回の半構造化、60分のインタビューを行いました。インタビューはビデオ会議を通じて行われました。インタビュー対象者は、自分の画面を共有し、ChainForgeで作成したものを説明するように求められました。ラボ内研究とは異なり、インタビュー対象者の画面録画は、スクリーンショットを撮ることを許可されない限り、プライベートに保持されました。なぜなら、実世界のユーザーはしばしば機密情報を扱っているからです。インタビュー対象者は自発的に自分の時間を提供しました。
我々は全32時間の画面録画とインタビューを文字起こしし、参加者の行動と参照を明確にするためのメモを追加しました（例えば、「インスペクタを開く; 上にスクロールする。十分に速かったようです... 最初のメールグループから読む「こんにちは...」」）。我々は概念的またはユーザビリティの問題と参加者の参照内容をメモしました。我々は、参加者のアイデア、行動（追加されたノード、彼らの探求のプロセス、データをインポートしたかどうかなど）、およびポストインタビューの質問への回答をリストするスプレッドシートを補完することで、親和性図法を通じた帰納的なテーマ分析を組み合わせてトランスクリプトを分析しました。ラボ内研究のために、3人の共著者はそれぞれ3つのトランスクリプトを別々に親和性図を作成し、その後、相互討論を通じてクラスターを結合しました。マージされたクラスターは、クラスターが飽和に達するまで参加者データで反復的に拡張されました。インタビューのために、最初の著者はすべてのトランスクリプトを親和性図法で分析して新たなテーマを特定しました。以下では、ラボ内の参加者をP1、P2などとし、インタビュー対象者をQ1、Q2などとします。
6 プロンプトエンジニアリングとLLM仮説テストのモード
人々は一般にLLMの振る舞いについてのプロンプトエンジニアリングと仮説テストをどのようなプロセスで行いますか？各研究の発見を詳しく説明する前に、一般的に参加者がChainForgeをどのように使用したかについての鳥瞰図を提供します。
研究全体での総合的な発見は、人々が機会主義的な探索モードから、限定的な評価モード、そして反復的な洗練モードへと移行する傾向があることです。私たちのラボ内ユーザーの約半数、特に以前の経験が限られているエンドユーザーは、探索モードを離れることはありませんでした。一方、プログラマーやLLMの監査者はすぐに限定的な評価モードに移行しました。いくつかのインタビュー対象者は、探索モードに対応するフローの切断された部分を持っており、その後、広範な評価パイプラインを明らかにするためにスクロールし、探索部分からプロンプトを評価に移行したと説明しました。セクション7.2では、各モードについて1つのケーススタディを提供します。これらのモードが、ユーザーがFigure 2の左側から右側に移動することにどのように対応しているかに注意してください。
機会主義的な探索モードは、プロンプト、入力データ、および仮説に対する迅速な反復、限定された数のプロンプトと入力データ、および複数モデルの比較によって特徴づけられます。ユーザーはプロンプト/検査/改訂を行います：いくつかのプロンプトを送り、結果を検査し、プロンプト、入力、仮説、およびアイデアを改訂します。このモードでは、ユーザーはモデルの振る舞いを探るために迅速な実験を行っています（「壁に物を投げて何がくっつくかを見る」、Q3）。たとえば、ジェイルブレイクのような敵対的攻撃を行った参加者は、異なるスタイルのjailbreakプロンプトを機会主義的に試し、特にどのモデルをバイパスできるかをチェックすることに興味を持ちました。 限定的な評価モードは、アドホックなプロンプトから評価のプロトタイピングへと移行することによって特徴づけられます。ユーザーは手動検査の限界に達し、LLMの振る舞いをより効率的に「一目で」テストしたいと考えています。これは、応答をスコアリングするために自動評価者をエンコードすることによって達成されます。ユーザーはプロンプト/評価/視覚化/改訂を行います：モデルをプロンプトし、チェーンの下流で応答をスコアし、結果を視覚化し、それに応じてプロンプト、入力データ、モデル、および/または仮説を改訂します。このモードの特徴は、ユーザーが分析パイプラインを設定し、評価自体を反復し、「入力データをスケールアップする」ことです。この段階での評価基準はしばしば「粗い」として「限定的」です。たとえば、事実性をチェックするのではなく、出力がまったく正しくフォーマットされているかどうかをチェックします。
反復的な洗練モードは、既に確立された評価パイプラインと基準を持ち、プロンプトテンプレートと入力データをさらにパラメータ化または直接編集することで調整し、調整の効果をチェックするための一回限りの評価を設定し、入力データの複雑さを増やし、モデルを削除または交換することが特徴です。ユーザーは調整/テスト/洗練を行います：パイプラインのある側面を修正またはパラメータ化し、調整が出力にどのように影響するかをテストし、「コントロール」と比較して、パイプラインをそれに応じて洗練します。限定的な評価と反復的な洗練の主な違いはチェーンの固さにあります：ここでは、ユーザーのプロンプト、入力データ、および評価基準が大部分安定しており、最適化を図っています（例えば、プロンプトを調整することや、失敗モードを特定するために入力データを拡張することなど）。いくつかのインタビュー参加者はこのモードに達し、プロンプトテンプレートを洗練したり、入力データを拡大したりしていました。プロンプトテンプレートやスプレッドシートをインポートすることで「プロンプトエンジニアリング」の問題を持ち込んだ数少ないラボ内参加者は、評価パイプラインを即座に設定し、このモードに移行しました。
これらのモードは示唆的であり、厳密に線形ではありません。例えば、ユーザーは限定的な評価を破棄して機会主義的な探索に戻ることがあります。以下のセクション7および8では、各研究の特定の発見に深く掘り下げます。ラボ内研究では、人々がプロンプトとモデルをどのように選択したかを説明し、各モードのケーススタディ（7.2）を提示し、概念的およびユーザビリティの問題について述べます。インタビュー研究では、ラボ内のユーザーと何が異なっていたかに焦点を当てます。
7 ラボ内研究の発見
平均して、参加者はインターフェイスを4.19/5.0（標準偏差=0.66）と評価しました。3未満を評価した参加者はいませんでした。スコアの理由を尋ねられたとき、参加者は一般的に小さなユーザビリティの問題を引用しました（例えば、ノードを接続するときに気難しい、色のパレット、フォントの選択、より多くのプロットオプションなど）。18人の参加者が再びインターフェイスを使用したいと望んでおり、5人は明示的に尋ねられる前にそう望んでいました。一部の人々は、モデル比較や複数応答生成を引用して遊びたいと思っていました。学術界または業界でLLMの振る舞いをテストした経験がある参加者は、ツールの主な価値として反復の速度と効率を引用しました（「これを使い始めていたら、私のプロンプトエンジニアリングでずっと進んでいたでしょう...これはJupyter Notebookよりもずっと速いです」とP4；「これは確実に私の半日を節約してくれるでしょう...これを使ってたくさんのことができます」とP21）。参加者は、異なるモデルとチャットするために複数のタブを開いている、スプレッドシートに手動で応答をコピーする、またはプログラムを書くといった以前の行動に言及しました。3人がChainForgeを学術研究に使用したいと望んでいました。
私たちは、モデルとプロンプトテンプレートを選択する構造化タスクでの参加者の行動、ChainForgeが参加者の探索と理解をどのようにサポートしたか、および痛点についての概要を語ります。
7.1 人々がモデルとプロンプトをどのように決定するか
人々は、並べられた応答を提示されたとき、テキスト生成モデルまたはプロンプトをどのように選択しますか？人々は、異なる基準と使用の文脈に対する応答品質のトレードオフを考慮するようです。参加者は、あるプロンプトやモデルが1つの基準や文脈で優れていると感じる一方で、別の基準や文脈では不十分であると感じました。別のプロンプトやモデルでは、その逆でした。ここでは、「基準」を我々の明示的な基準だけでなく、参加者の暗黙の好みも意味するように自由に使用しています。参加者はまた、暗黙的に基準をランク付けし、一部を他より重視し、基準間の摩擦を参照しました（例えば、P2は「専門的なものを簡潔なものより好む、なぜならそれメールは簡潔であることができるが、誤解されるかもしれないからです」）。さらに、異なる基準に対応する応答の側面をよりよく表面化する各プロンプトパフォーマンスの複数の表現を見ることは、参加者の理論化と意思決定に影響を与えることがあります。ここでこれらの発見を詳述します。 構造化タスクの最初の部分では、どのモデルが「より良い」パフォーマンスを示したかについての合意はありませんでした：8人がPaLM2を選び、7人がGPT-4を、6人がClaude-2を選びました。理由にパターンはありませんでした。参加者はそれぞれのモデルの応答スタイルの類似した特徴に気付きましたが、そのスタイルをどのように評価するかは異なりました。いくつかの参加者は、他の人が嫌う理由でいくつかのモデルを好みました。たとえば、P1はその長いメールのためにPaLM2を賞賛しましたが、P17は「PaLM2は長すぎる」としてGPT-4を選びました。私たちが意図的にClaudeの出力に対して最初の基準を設計したにもかかわらず（その説明情報のため）、一部の参加者はまだClaudeを好み、その説明を想像されるユーザーにとって有用と見なし、またはそのライティングスタイルを好みました。非構造化タスクでは、アプリを開発している参加者も、モデルを比較する際に価格、アクセス、応答時間などの外因性要因に言及しました。人々は複数のプロンプトの中からどのようにして1つを選択しましたか？モデルを選択するときと同様に、参加者は異なる基準と文脈間のトレードオフを考慮するようです。複数の表現（例えば、プロンプトパフォーマンスのプロット）を持つことは、特にユーザーに異なる「視点」を提供し、理解と理論化を増強することができます。P1は、手動検査とプロンプトによる応答長のプロットの両方を参照しながら、自分とユーザーのニーズの間の緊張を説明します：
「もし私が開発者なら、この3番目のプロンプトが出力をより良く通過させるのに役立つので好きです...しかし、彼らユーザーがこのグラフ(Visノード)を見る機会があれば、おそらくこれ(2番目のプロンプト)を選ぶでしょう。なぜなら、それが彼らのニーズに合っており、より簡潔だからです(箱ひげ図は最小の中央値と最低の変動性を持っています)...だから、それは視点に依存します。」
複数の表現は、プロンプティング戦略についてのユーザーの理論化を増強することもできます。たとえば、P17は3つのコマンドプロンプトを持っており、各イテレーションではデフォルトのプロンプトの最後に単により多くのフォーマット指示を追加しています（Figure6）
https://scrapbox.io/files/65bc706389a235002431846f.png
彼女は彼女のプロットとテーブルレイアウトを比較しながら理論化します：「「メール形式で応答を生成する」と追加した後、それをより長くしました...しかし、「簡潔な言葉遣いで」と言わないとき...時々、本当に単純なリクエストのために3つの段落を生成することがあります。そのため、私は二番目の指示に従うことにしました...そしてその長さの差(変動)が少ないです。」一つのプロンプトがより短い、または変動が少ない反応を引き出したことが参加者に、以前の意見を見直すきっかけとなるかもしれません。プロットを通じて自分の最初のコマンドが「より一貫しているように見える」と気づいた後、P4はそれを選んだプロンプトにその特徴を取り入れ、後者の簡潔さを改善したいと思いました。なぜなら、彼は依然として後者のテキストの質を好んでいたからです。これらの観察は、手動検査によって引き起こされる固定観念を、系統的な評価が争うことができることを示唆しています。しかし、これはまた、ユーザーが複数の表現を必要とするか、または一つの表現で最も簡単に見つけられる特徴によって偏った決定を下す可能性があることも明らかにします。複数を持つことで、彼らはより自信を持って決定を下し、それぞれのプロンプトから部分を混ぜ合わせて、想像される理想に向かって進むことができます。プロンプト比較の利点はまた、多様なプロンプトから始めることの重要性を強調しています—過去の研究と同様に、参加者の多くは多様なプロンプトを思いつくことに苦労し、13人は私たちの初期のコマンドプロンプトをわずかに変更していました。このことについて、私たちはディスカッションでさらに反省します。
7.2 使用モードのケーススタディ
参加者は未構造化のタスクにさまざまなアイデアを持ち込み、LLMの振る舞いの監査から、生産中の確立されたプロンプトの洗練までを行いました。参加者はしばしばインターネットを検索し、事実データをクロスチェックしたり、Redditからプロンプトをコピーしたり、オンラインインタープリタでコードを評価したりしました。9人の参加者がフローで使用するデータをインポートしました（そのうち6人はスプレッドシートをインポートしました）、しばしば研究中に私たちにデータを送信しました。
人々がChainForgeをどのように使用し、彼らの相互作用がどのように異なるかを理解するのを助けるために、私たちは3人の参加者の経験を通じて説明します。各ケーススタディはセクション6からの1つのモードに対応します。
7.2.1 機会主義的探索モード：モデルの振る舞いを迅速に発見することを通じて、仮説に対する反復。
インドネシアの大学院生であるP15は、AIモデルがインドネシアの教育参加率をどの程度知っているか、そして「私たち教育者として将来何をする必要があるか」についてのアドバイスをどのように提供できるかをテストしたいと考えていました。彼女はインドネシアの中央統計局であるBadan Pusat Statistik (BPS)からの公式データを含むブラウザタブを開きます。彼女は「異なる言語を使用した場合、何が違うのか？」を知りたいと思っています。彼女はTextFieldsを2つのフィールドで追加します。1つ目のプロンプトは英語で「インドネシアの学生が大学に通う参加率を教えてください」、2つ目はそのインドネシア語訳です。「とりあえず2つ試してみましょう。どうなるか見てみたいだけです。」反応を収集し、彼女は3つのモデルへの英語のプロンプトに対する横に並んだ反応を見ます。全てのモデルは異なる年とパーセンテージを提供します。インドネシア語のプロンプトのための反応グループをスクロールダウンして拡大すると、彼女はFalcon.7Bが彼女のプロンプトを繰り返すだけで、PaLM2モデルがセーフティフィルタを引き起こしていることを発見します。最後のモデル、GPT-3.5は、その英語の反応とは異なる統計を与えます。これらの反応を1分未満で見て、P9はAIモデルの振る舞いの3つの側面を発見しました：まず、モデルは「事実」において異なるということ、第二に、一部のモデルは非英語の言語で問い合わせられたときに答えを拒否することがあるということ、第三に、同じモデルが異なる言語で問い合わせられたときに事実において異なるということです。彼女は各数値をBPSの統計と比較し、それらが不正確であることを発見します。「ああ、神様、私は好奇心が強い。なぜ彼らはモデル間で異なる答えを持っているのか？」彼女はPrompt Nodeにモデルを追加します。「全てのモデルを試してもいいですか？テーブルに載っているか見たいです。」
彼女は新しいモデルに問い合わせます。新しい仮説が生まれます。「私たちのプロンプトで、データの出典を言う必要がありますか？それはもっと正確になるのではないでしょうか？」彼女は異なるモデルが異なるデータソースからデータを引っ張っているのではないかと疑います。反応を検査すると、いくつかのモデルがデータソースを引用していることがわかります：ClaudeはUNESCOを引用し、GPT-4は世界銀行、UNESCO、インドネシアの教育文化省を引用しています。彼女のインドネシア語のプロンプトに対して、彼女は同じモデルが反応でBPSのみを引用していることを発見します。「BPSはインドネシア語を使ったときにのみ言及されます... 英語のプロンプトでは... よりグローバルな感じ... ああ、違う言語を使うと、データの出典も異なるというのは本当に興味深いです。」
彼女はプロンプトテンプレートに第二のプロンプト変数、{organization}を追加します。彼女はそれに世界銀行、UNESCO、Badan Pusat Statistikの値を添付します。再び問い合わせを送り、反応を検査すると、彼女はBPSのための両方のインドネシア語と英語の反応グループのサブグループを拡大し、その二つのサブグループが同じ画面上にあるようにします。英語でBPSのデータを尋ねると、GPT-3.5とClaudeの両方が答えを拒否しますが、同じモデルはインドネシア語で尋ねられたときにBPSの数字を提供します。さらに、Claudeの英語の反応は、代わりに世界銀行とUNESCOのデータを見ることを読者に提案しており、それらのソースを引用しています。「それは本当に興味深いです。わあ。」
この研究がここで終わったとしても、このケースは仮説の反復、限定されたプロンプト、そしてモデル間の比較に対する熱意という、機会主義的探索モードの重要な側面を示しています。より多くの時間があれば、ユーザーは英語で問い合わせた場合にモデルが「グローバル」な情報源をどのように引用するか、インドネシア語と比較して評価を設定するかもしれません。
7.2.2 限定評価モード：事実の正確性をスポットチェックするための評価パイプラインの設定。
どのようにユーザーは探索的モードから限定評価モードへと移行するのでしょうか？私たちは、ポリマーへの添加剤の導電率値を理解するLLMをチェックするためにChainForgeを使用した材料設計の学生、P18の評価のプロトタイピングと「スケーリングアップ」を例に挙げて説明します。この例はまた、ユーザーがスケールアップしようとしたときの使い勝手の問題を描写しています。
ケース#1のように、P18は機会主義的探索モードで始まります。彼らはプロンプト/検査/改良—クエリを送り、反応を検査し、入力データまたはプロンプトを改訂します。彼らはBaseと添加剤という2つの変数を持つプロンプトテンプレートを作成します（Figure 7）。
https://scrapbox.io/files/65bc71787771a400241564b0.png
最初はベースを一つだけ、添加剤を四つ使い始めます。反応を検査したP18は、P18の幅広いカテゴリーの下で特定の添加剤を提案し説明するGPT-4の能力に感心しました（例えば、イオン液体のEMIMBF4）。彼らは質問を洗練させます。「私はおおよその導電率値を推定したい。」彼らはプロンプトテンプレートを修正し、「そして導電率値を推定する」と追加します。反応をレビューした後、彼らは数値の範囲が大体正しいと判断します。それから、手動検査よりも体系的に数値を検査したいと考え、限定評価モードに移行します。研究者は、導入ビデオで一度だけ見た評価ノード、LLMスコアラーを使用して数値を抽出する方法でP18を支援します。このノードを使って、ユーザーは自然言語のプロンプトを入力して反応を評価することができます。P18はスコアラープロンプトに対してプロンプト/検査/改良のループを繰り返します：最初に単に数値を尋ね、時々単位が出力されることを発見した後に「単位なしで」と追加します。「これは良いです。だから私たちはいくつかのVisノードを追加します。」彼らはy軸に添加剤をプロットして（Figure 7）。「とても良いです。研究者：これは本当ですか？大体、はい。大体です。」P18はその後、ベース変数に二つ目のポリマーを追加することで「スケールアップ」したいと考えます。彼らは導電性ポリマーの略称、ポリアニリン（PANI）をGoogleで検索します。それを二つ目のフィールドとして貼り付け、プロンプトとスコアラーノードに再クエリを送ります。テーブルレイアウトでスコアを2秒でざっと見ると、「おお、すごい... 本当に良いです。なぜならPEDOTが最も導電性が高いからです。」Visノードを検査すると、彼らは使い勝手の制限に遭遇します：彼らはベースごとにグループ化したいのですが、y軸に添加剤がプロットされたときにはそれができません。ベースをy軸にプロットすると、彼らは箱ひげ図を通じてPANIがPEDOTよりも集合的に低いことを見ます。彼らは研究者に評価スコアをエクスポートするよう依頼します。この例は限定評価モードを示しています、例えば評価パイプライン（スコアリングプロンプトの洗練）の反復、およびパイプラインが設定された後に入力データを拡張することで「スケールアップ」を始めること、などです。ユーザーはまた、スケールアップする際に使い勝手に関する摩擦に遭遇しました。入力データの複雑さが増すにつれて、より多くの視覚化オプションを求めました。 7.2.3 反復的洗練モード：最適化を試みるために確立されたプロンプトとモデルを微調整する。
P8はドイツのスタートアップで働いており、プロンプトエンジニアリングの問題を持ち込み、LangChainからデータセットとプロンプトテンプレートをインポートしました（「私たちはeコマース会社のためのカスタムLLMアプリ、バーチャルショップアシスタントを構築しています」）。このテンプレートはすでに大幅な改訂を経ていたため、参加者は即座に反復的洗練モードに移行し、私たちのインタビュー研究中には後からしか垣間見ることのできなかった相互作用を観察することを許可しました。P8のスタートアップはGPT-4を使用していました（「ドイツ語のGPT-3.5は本当にそれほど良くないから」）、しかし他のモデルがより良いパフォーマンスを発揮するかどうか興味がありました。彼はClaudeとPaLM2を知っていましたが、カスタムAPIコールをコーディングする必要があるために敬遠していました。彼はまた、ドイツ語のプロンプトに英語を部分的に使用すると、より良い結果が得られるという仮説を持っていました。非構造化タスクに取り組む際、彼はスプレッドシートをインポートし、表形式のデータノードに貼り付け、プロンプトノードに3変数のテンプレートを貼り付けてそれらを接続しました。その後、Python 評価ノードを追加して、テンプレートに設定した長さの制約をLLMが守っているかどうかをチェックしました。グループ化されたリストレイアウトを使用して、変数product_informationに対する10の入力値に対するClaudeとGPT-4の応答を比較しました。「GPT4は長すぎる... Claudeはかなりうまく制限内に収まっているようです—別の応答グループを開く、実際、ここに外れ値があります。」手動で応答を見ながら、彼は研究前に自分の10の基準に沿って各応答を手動で評価していたことを示唆しています。「ほぼ10の指示を出しました...公式の言語、長さなどです。そして各...今、私はそれをレビューする必要があります。」Claudeの応答の一つがBegleiterという言葉を含んでいることに気づきました。これは彼が明確に除外するよう指示した言葉でした。「それはGPT-4で繰り返し使用されていたパターンだったからです...だから今、Claudeがこの指示を英語で与えた場合にどのように振る舞うか試してみるつもりです、ドイツ語ではなく。」 これをテストするために、彼はプロンプトテンプレートの「以下の単語を避ける」部分を新しい変数{avoid_words_instruction}に抽象化しました。以前のコマンドをTextFieldsに貼り付け、2つ目のコマンド（同じコマンドですが英語で）を追加しました。シンプルな評価ノードを追加して、応答にBegleiterが含まれているかどうかをチェックしました。グループ化されたリストレイアウトで、avoid_words_instructionによって応答をグループ化し、「スコアのみ表示」をクリックして真偽値（赤で偽）のみを表示します。一見して、「統計的に有意ではない。しかし...GPT-4は決して間違えず、Claudeは英語でもドイツ語でも間違えました...だから、どの言語であっても...Claudeは依然として指示を破ります。」彼は別の用語をテストするために別のシンプルな評価ノードを追加し、実際にはすべてのケースを一度にテストするためにPythonスクリプトを書くだろうと述べましたが、研究には時間が足りません。「だからClaudeはまた両方の場合にそれを破ります...しかし英語では、それは再び一度だけ違反し、ドイツ語では2回違反します。だから、多分それは徐々に統計的に有意になっているかもしれません。」研究が終わると、彼は自分の元の選択を正当化すると宣言しました。「おそらくGPT-4を使い続けるべきだろう。」 ここでは、反復的な洗練モードの側面を見ています—参加者はすでに彼のプロンプト（パイプライン）を最適化しており、特定の基準に従って出力をさらに改善できるかどうかを見るためにプロンプトとモデルを調整しようとしています。私たちが構造化タスクで見つけたように、意思決定を行う際、ユーザーは異なるモデルやプロンプトが特定の基準をどのように満たすか、および基準の重要性をどのようにランク付けするかの間のトレードオフを考慮します。P8にとって、彼の「避けるべき単語」の基準はミッションクリティカルであるように見えましたが、Claudeがより良く守ると彼が認識していた単語数は明らかにそれほど重要ではありませんでした。
7.3 ChainForgeは参加者のAIの行動や実践に対する理解に影響を与えました
インタビュー後、15人の参加者が自分のAIに対する理解が経験によって影響を受けたと述べました。6人はClaude-2やPaLM2のパフォーマンスに驚き、OpenAIのモデルと直接比較したとき、これらが後者のパフォーマンスに匹敵するかそれを超えると感じました。5人はプロンプティングまたはプロンプトエンジニアリングの戦略が変わったと言いました（「以前は、これらのことを効率的に行っていませんでした...わずかな修正を加えて再実行し、それには数時間かかります...ここではすべてが私のために用意されているので、諦めたくありません」とP4）。AIモデルをプロンプトしたことがないP16のように、AIモデルに不慣れな他の人々は、一般的な振る舞いについて学びました。「異なるモデルが私のプロンプトをどのように理解し、それに応じて応答するか、完全に異なる方法があることに気づきました。彼らはまた、完全に異なる応答スタイルを持っています。」ケーススタディ7.2.1で取り上げられたP15は、AIに対する「信頼」を失ったと言いました。
7.4 課題と痛みのポイント
多くの参加者がChainForgeから価値を得たとはいえ、彼らの経験が無問題だったわけではありません。多くの使い勝手の問題は、ノードを動かしてスペースを作る必要があるなどのフローUIを中心に発生しました。また、変数のプロット順序の不一致や、色と視覚化のコントロールをもっと欲しいという関連の問題もありました。一部の参加者は概念的な問題にも直面しましたが、これは時にユーザーがインターフェイスに慣れることを示すことがあります。最も一般的な概念的な問題は、プロンプトテンプレートの仕組みを学ぶことであり、特に、プロンプトノードで入力変数を宣言することを忘れることでした。しかし、ユーザーがテンプレートを学ぶと、この問題はしばしば消えました（「プロンプト変数...学習曲線が少しありますが、デザインの選択は理にかなっていると思います」とP13）。テンプレート変数を学ぶことは、過去のプログラミングの専門知識に関連しているようであり、AIではありません。これは、以前にプログラミングの経験がないユーザーが追加のリソースを必要とすることを示唆しています。
研究室では、研究者がユーザーを支援するために手元にいました。ユーザーがアイデアを提案していたとしても—しばしば非常にドメイン固有のもの—研究者はそれらを実装する方法や概念的な障害を克服する方法をユーザーに提供することができました。AIモデルやLLM APIでのプログラミングに以前から経験がある一部のエンドユーザーやユーザーでさえも、「スケールアップ」すること、または評価を体系化することに苦労しているように見えました。たとえば、P10はPythonの専門家として自分を5と評価し、LLMイメージモデルに関する以前の研究を行っていました。彼らはプロンプトテンプレート、プロンプトノード、チャットターン、シンプルな評価者、Visノードを備えた印象的な評価を設定しましたが、最終的には複数のモデルに単一のプロンプトを送信するだけでした。この振る舞いについては議論でさらに述べます。
8 実際のユーザーとのインタビュー
私たちのインタビューの発見は、ラボ内の研究と補完しあっていますが、重要な点で異なります。ラボ内の参加者と同様に、実際のユーザーもChainForgeの機能を称賛し、私たちが設計した目標—モデルの選択やプロンプトテストなど—のためにそれを使用しましたが、実際のユーザーが気にかけていたいくつかのことは、ラボ内の参加者によってほとんど、あるいは全く言及されませんでした。データを分析し、ラボ内研究と比較したところ、多くのユーザーのニーズや問題点が、彼らがChainForgeをデータ処理パイプラインのプロトタイピングに使用している事実に関連していることがわかりました。これはより広い文脈で、私たちがChainForgeのサポートを設計したタスクを、より大きな目標のサブタスクとして再定義します。インタビューされた人々は、ChainForgeからのデータのエクスポートと共有の容易さ、プロセッサノードの追加、共有と迅速なイテレーションのためのInspect Nodeの重要性、そしてプロジェクトのオープンソース性が、彼らのユースケースにコードを適応させる能力について最も多く語りました。これらの洞察については以下で詳しく述べますが、まず、ChainForgeから実際のユーザーが得た類似点、ユースケース、具体的な価値を総括して概観します。
インタビュー参加者をテーブル2にリストし、ユースケースと使用したノードを記載しました。アウトカム列はChainForgeが提供した実用的な価値を示唆しています。Q1とQ2の主なユースケースは、HCI研究プロジェクトを支援するためにソースコードを構築することでした。インタフェースの6人のユーザー全員が、プロンプトやパイプラインのプロトタイピングとイテレーションに特に有用であると感じました（例えば、Q5は「ChainForgeのユースケースを非常に良いプロンプトプロトタイピング環境として見ています」）。使用状況は限定的な評価と反復的な洗練のモードを反映しており、複数の参加者がプロンプト/評価/視覚化/改訂のループを説明しています：LLMにクエリを送り、応答を評価してプロットを見て、望ましい結果に達するまでプロンプトを洗練するかモデルを変更します。たとえば、Q3はプロンプトテンプレートを微調整して、すべての入力データにわたってVis Nodeの100％バーを最大化することで、LLM出力が一貫したフォーマットになるまで調整しました。一部の参加者は、より広いLLMOpsエコシステムから欠けている迅速なプロトタイピングツールとしてChainForgeを見ており、「実際にハードコードに書き込める段階に達するまで」使用していました（Q4）。3人はChainForgeが相対的なパワーに対してノードが少ないことを評価し、他のノードベースのインターフェースと比較して印象的だと感じました（例えば、Q8は「これは印象的です。少ないもので成し遂げることができること」）。新しいノードを追加しすぎると、新規ユーザーにとってインターフェースがより威圧的になることを心配していました。Q4とQ7は、JupyterノートブックよりもChainForgeを効果的だと感じました（Q7は「ChainForgeを楽しんでいます...なぜなら、私はワークフロー全体を何度も繰り返し実行でき、...Jupyterではそれが簡単ではありませんでした」）。このセクションの残りの部分では、ラボ内研究との違いについて詳しく説明します。
8.1 データ処理パイプラインのプロトタイピング
5人のインタビュー対象者は、ChainForgeをプロンプトエンジニアリングやモデル選択だけでなく、LLMを含むデータ処理パイプラインのオンデマンドプロトタイピングに使用していました。すべてのユーザーはスプレッドシートからデータをインポートし、多くのパラメータ化されたプロンプトを送信し、プロンプトテンプレートとパイプラインを反復し、最終的には他の人と共有するためにデータをエクスポートしました。このようなユーザーはChainForgeを少なくとも1つの意図された設計目標に使用していましたが、常にそれらのより大きなデータ処理目標のサービスでした。Q7にとって、「このプロセス全体、データクリーニングを支援するパイプラインを書くことがアイデアでした。」彼にとって、ChainForgeは「特定のもの、例えばデータセットに使用したいさまざまなプロンプトがあるとき、または何かを探求したり調査したりしたいときに理想的です。」別のユーザーであるQ3は、洗練されたフローを開き、1つの値を編集し、再実行してから、応答をスプレッドシートにエクスポートしました。他の参加者と同様に、彼はChainForgeの組み合わせのパワーを他のツールと比較して主要な利点として挙げました（「このツールはプロンプトの洗練に強い。Flowiseでは...複数の入力フィールドを試したいとしましょう。それを実行できるとは思わない」）。参加者はまた、プロトタイピングプロセスの一部として入力データを反復することについても言及しました。最後に、データ処理に関連して、3人のユーザーはLLMの応答を連結するための「結合」ノードのようなプロセッサノードを望んでおり、1つのケースでは、連結をエミュレートするために別のフローにLLMの出力を手動でコピーしていました。多くのニーズと問題点はデータ処理に関連しています。
8.2 データの取り出しと他者との共有
多くの参加者はChainForgeからデータをエクスポートしたいと考えていました。これは特に、プロトタイピング段階から製品段階への移行時に、ChainForgeの強みとして認識された段階から、環境を変更する際の負担やギャップを締めることが有効だと感じる場合に、最も一般的な問題点でした（例えば、「このプロトタイピング段階を抜け出したときに、それが役立つと思います...」、Q5）。ニーズは2つのカテゴリに分かれます：他のアプリケーションに統合するためのエクスポートと、他の人と結果を共有するためのエクスポートです。前者については、開発者ユーザーはChainForgeを使用してプロンプト、モデルの挙動、および/またはプロンプトチェーンを試験し、その後、フローをテキストファイルやアプリ構築環境に簡単にエクスポートできる方法を望んでいました。後者については、5人のインタビュー対象者が他の人と結果を共有しました。これはファイル、フローのスクリーンショット、応答のエクスポートされたExcelスプレッドシート、またはコピーされた応答を通じて行われました。Q5とQ6はInspect Nodeの重要性を強調しました。これはラボ内の参加者が使用または言及しなかったノードです（「一度結果が文書化する価値があると判断されたら、Inspectノードを作成します。」）。彼らはフローのスクリーンショットを撮り、クライアントに送り、1つのケースではクライアントをプロジェクトを進めることに説得しました。他者と共有する予測は行動を変えることもあります。Q3は単一の値を持つ複数のTextFieldsノードを持っていました。「他のチームが変更したいと思うかもしれないものだとわかっていたからです。」共有はまた、分析結果の共有可能な「レポート」をより簡単にしたいと望む2人にとって痛点でもありました。
8.3 痛点：隠されたアフォーダンスと機会探索モード中の摩擦
ラボ内の参加者と同様に、インタビュー対象者も使い勝手と概念的な問題に直面しました。一般的なテーマは、既に存在するが比較的隠されている機能を必要とする個々のユーザーが表明したことであり、これらは例やドキュメントを通じてのみ明らかにされます。これらの隠されたアフォーダンスには、暗黙のテンプレート変数、メタ変数、およびテンプレートチェーンが含まれます。前者2つの機能は、チェーンのさらに下流で入力データまたは応答に関連するメタデータを参照するユーザーのニーズに対応します。もう1つの痛点は、機会探索フェーズ中の摩擦でした。セクション6では、いくつかのインタビュー対象者が彼らのフローの中に切断された領域を持っていると述べました。そのうちの一つを私たちは「機会探求モード」と呼んでいます（入力データ、プロンプト、モデル、仮説を通じての迅速な、初期段階の反復；通常は3ノードの連鎖、TextField-Prompt-Inspect）。このモードでは、いくつかのインタビュー対象者は、迅速な反復を容易にするために、ポップアップウィンドウではなくフロー上で直接レスポンスを検査することを好みました。彼らは、別のノードを接続する必要なく、LLMのレスポンスをより即座に、文脈内で読む方法を望んでいました。
8.4 オープンソースの柔軟性
複数のインタビュー対象者が私たちのソースコードを見ており、2つのプロジェクトがそれを拡張しました。ドイツ政府と協力するコンサルティング会社の従業員であるQ5とQ6は、設定画面を備えたドイツベースのLLMプロバイダー、AlephAlphaにコードを拡張しました。彼らは、ヨーロッパのビジネスとGDPRデータ保護法を支援する価値を引用しました。「ドイツ政府はそれを支援したい...地元のプレイヤーです...そして、データを隠す強いニーズがあります。つまり、GDPRはこの点で非常に厳格です。」彼らの目標は、OpenAIモデルよりも、彼らのユースケースにとってドイツモデルに切り替えることが「理にかなっているかどうか」を決定するためにChainForgeを使用することでした。HCI研究者のQ1とQ2は、ツールとの主な関わりがそのソースコードで、LLM画像モデルプロトタイピング用のフローベースツールのプロジェクトを始めるための助けとなることを発見しました。Q2は、「キャッシング、プロンプトノードのプログレスバー、およびマルチモデルクエリに対する考え」を評価し、「ChainForgeの設定が非常に簡単で、拡張するのも驚くほど簡単だった...期待していたよりもずっと簡単だった」と付け加えました。彼らは、ChainForgeが提供したジャンプスタートが、彼らが年次CHI会議に論文を提出するためにプロジェクトを時間内に完成させる主な理由だったと述べました。
9 討論と結論
私たちの観察によると、ChainForgeはそれ自体で有用であるだけでなく、「可能にする」貢献としても有用であり、他の人が自分自身のアイデアやトピックを調査するために拡張できる（そして拡張している）オープンソースプロジェクトです。ChainForgeが数ヶ月前にのみリリースされたことを考えると、ここで紹介されたストーリーは、その実際の世界での有用性の証拠を提供すると信じています。この論文の残りの部分では、私たちの主要な発見をレビューします。私たちの作業は、実際の使用に関するデータを持つ唯一の「プロンプトエンジニアリング」システムの貢献の一つを代表しており、構造化されたタスクに関するラボ内研究とは対照的です。実際のユーザーが気にかけていたいくつかのこと、例えばデータのエクスポートや共有のための機能は、私たちのラボ内研究から欠けていた—そして実際には、類似のLLMプロンプトシステム研究からも欠けています。最も驚いたこと（私たちにとって）は、知識労働者のいくつかが、私たちが予想していなかったタスク—データ処理—にChainForgeを使用していたことです。インタビュー研究ではインターフェイスユーザーが6人しかいませんでしたが、スタートアップのラボ内参加者2人、P8とP4は、LLMがデータを処理して再フォーマットする能力をテストしていました。以前のLLMツールは、センスメイキング、プロンプトエンジニアリング、またはアプリビルディングをターゲットにしていますが、データ処理を特にターゲットにしているわけではありません。私たちの発見は、LLMを含むデータ処理パイプラインのオンデマンド作成をサポートするシステムの必要性を示唆しています。ChainForgeの組み合わせの力—多くのクエリを一度に送信する能力、インポートされたデータによってパラメータ化された—は、このニーズをサポートするための鍵であるように見えました。将来のシステムは、ユーザーがそのチェーンのさらに下流で上流のメタデータをよりアクセスしやすい方法を提供することによってさらに進むべきです。次に、プロンプトエンジニアリングとLLM仮説テストの3つのモードを特定しました：機会探求、限定評価、および反復的改善。最初のモードは、GitHub CoPilotのためのBarke et al.の探求モードに似ています。将来のシステムは、作業を設計しフレーミングする際にこれらのモードを明示的に考慮すべきです。たとえば、ユーザーはしばしば、最初に試したプロンプトを洗練する反復的改善モードにあまりにも速く入ります—一つを探る前にいくつかを探ることなく。プロンプトエンジニアリングツールが反復的改善のみをターゲットにしている場合、機会探求段階—始めるための良いプロンプトを見つける—はあまりにも速く端折られ、ユーザーを潜在的に最適でないプロンプト戦略に閉じ込めるかもしれません。これらのモードはまた、設計の機会を示唆しています。たとえば、私たちはChainForgeの設計が、文脈内でLLMのレスポンスを検査するより単純な方法を望む一部のユーザーによって、機会探求モードをよりよくサポートできたと信じています。一つの設計ソリューションは、それぞれ専用のインターフェースを備えた、探索モードのためのよりチャットのようなインターフェイスに各モードを具体化することかもしれません。これにより、後のモードへの移行が容易になります。以前のLLMプロンプトシステムは、機会探求または反復的改善をターゲットにしていますが、小規模で手早く雑な評価をプロトタイピングすることによって大きな理解への道を特徴づける重要な中間点である限定評価を見落としています。将来の作業は、オンデマンドLLM評価パイプライン自体のプロトタイピングをターゲットにするかもしれません。第三に、人々が異なるプロンプトとモデルを選ぶとき、彼らはパフォーマンスのトレードオフを異なる基準と文脈で考慮し、意思決定に自分自身の視点、価値観、好み、および文脈を持ち込みます。レスポンスの複数の表現を持つことは、参加者がトレードオフを考慮し、プロンプトとモデルをランク付けし、より良いメンタルモデルを開発し、より自信を持ってプロンプトまたは仮説を改訂するのに役立ったようです。人間の学習の理論に接続すると、7.2.1のケーススタディは、クロスモデル比較が、AIへの過度な依存を驚かせることによって、初心者がAIのメンタルモデルを改善するのにも役立つかもしれないことを示唆しています。モデルとプロンプトを選択することの主観性は、LLMが確かにユーザーがプロンプトを生成または評価するのを助けることができる一方で、完全に自動化されたプロンプトエンジニアリングというものは決して存在しないことを意味します。プロンプトエンジニアリングを（純粋に）最適化問題として枠組みするのではなく、プロジェクトはユーザーが検索プロセスをよりコントロールできるようにする方法を探すべきです。最後に、ユーザーが実際のタスク、実装、および反復についてChainForgeを有用だと見つけた一方で、概念化と計画の側面についてはもっと作業が必要です。ラボ内のユーザーは、LLM APIを使ったAIやプログラミングの事前の専門知識を持つ人でさえも、テストを体系化することを想像する能力に限界があるようでした。これは、「非AI専門家」がLLMにプロンプトをどのように提示するかを研究する以前の作業を拡張しており、他の場合では自分自身をAIの専門家とみなしている人々でさえも、評価を体系化することに問題があるかもしれないことを示唆しています。LLMは非決定論的で（少なくとも、非ゼロの温度で頻繁にクエリされる）小さな摂動から予期しない行動のジャンプに傾向があるため、将来のシステムとリソースが固執を減らし、ユーザーを初期の探索から体系的な評価へと導くのに役立つことが重要です。例えば、監査ツールAdaTest++は、専門家の監査戦略を再利用可能なプロンプトに変換する「プロンプトテンプレート」をユーザーに提供することで、より特定のユースケースを対象としたツールからコンセプトを活用できるかもしれません。他の作業は、プロンプトの作成や「プロンプトスペース」の検索をサポートしています。体系化/スケーリングアップをサポートするために、評価戦略を概説するAIとチャットするユーザーの相互作用も採用できます。
9.1 限界
私たちが質的評価方法論を使用する選択は、ツールキット研究周辺のよく知られた困難、生態学的妥当性に関する懸念、そして最も重要なことに、ChainForgeの全機能セットに一致する既存の確立されたインターフェイスを見つけることができなかったという事実に由来しています。したがって、私たちの目標は、将来の作業が改善できる基本的なシステムを確立することでした。私たちの質的評価がいくつかの重要な発見をもたらしたと信じていますが、特定の科学的質問に答えるために、ChainForgeインターフェースの部分に対してより定量的でコントロールされたアプローチを実施すべきです。私たちのラボ内研究も比較的短期間（75分）でした；将来の研究では、例えば数週間にわたるワークショップで、ユーザーの行動の変化を観察するかもしれません。最後に、私たちのインタビュー研究については、参加したインタビュー対象者が既にChainForgeを有用だと見つけている可能性があり、そうでないユーザーを見落としている自己選択バイアスを認めます。私たちのラボ内研究はいくつかの洞察を提供しましたが、ユーザーのプログラミングへの事前の露出が彼らの経験の質に重要であったと推測します。